I need some support on the return type hint for view_to_component

Since the decorator is polymorphic, I can't figure out how to annotate how this decorator can be used with or without parenthesis.

The current annotations do not work properly when parenthesis are used, such as in our tests.

You'd handle that polymorphic behavior with @overload. Typing this correctly can tricky. Don't have time to give a full example now, but can help if needed.

Support on that would be great.

You can either commit it directly to this branch, or we can push this PR forward and PR proper type hints later.

Here's a sample of what the overload might look like:

@overload
def view_to_component(view: Callable | View) -> _ViewComponentConstructor: ...

@overload
def view_to_component(view: None = ..., other_params: Any) -> Callable[[Callable], _ViewComponentConstructor]: ...

# final definition
def view_to_component(view: Callable | View | None = None, other_params: Any) -> _ViewComponentConstructor | Callable[[Callable], _ViewComponentConstructor]: ...

Dang, overload is pretty neat.

I needed to do some modifications in order for the type hints to also work for use cases such as:

_view_to_component_kwargs = view_to_component(views.view_to_component_kwargs, compatibility=True)

I believe I got something pretty solid in terms of type hints. But I'm not sure why the github actions mypy has issues with it when my local mypy --show-error-codes src/django_idom does not.

@rmorshea not sure why my local MyPy doesn't generate warnings but GitHub actions does.

I think it's worthwhile to keep the ignores in tests/*. Having mypy lint the tests helped in letting me detect when the @view_to_component decorator type hints were broken.

Perhaps we should run mypy on our tests then?

Done

Hopefully we can push this out today. I'd like to get the VTC security warning on the docs ASAP

I think we can merge this, but I'm a little uncertain whether running MyPy against our test suite is the right move. I'm worried that the benefits of doing so don't outweigh the burden it might places on potential contributors. MyPy allows for per-module configuration, so perhaps, in a follow-up PR, we could tweak our MyPy configuration for our tests to be more lenient than the configuration we apply to our tests.

I don't mind not running the test suite on the tests/ folder via workflows. But I'd like to be able to verbosely see errors when actually typing the tests.

Increasing test leniency might reduce the API/typehint bugs I manually catch while writing test.

MyPy is pretty configurable so I'm pretty sure we could strike a nice balance.